<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="generator" content="Docutils 0.4: http://docutils.sourceforge.net/" />
<title>Basic Platform Independent Non-Volatile Storage Layers</title>
<meta name="authors" content="David Moss  Junzhao Du  Prabal Dutta  Deepak Ganesan  Kevin Klues  Manju  Ajay Martin  and Gaurav Mathur" />
<style type="text/css">

/*
:Author: David Goodger
:Contact: goodger@users.sourceforge.net
:date: $Date: 2009/02/03 23:07:32 $
:version: $Revision: 1.2 $
:copyright: This stylesheet has been placed in the public domain.

Default cascading style sheet for the HTML output of Docutils.
*/
body {
  font-family: Times;
  font-size: 16px;
}

.first {
  margin-top: 0 ! important }

.last {
  margin-bottom: 0 ! important }

.hidden {
  display: none }

a.toc-backref {
  text-decoration: none ;
  color: black }

blockquote.epigraph {
  margin: 2em 5em ; }

dd {
  margin-bottom: 0.5em }

div.abstract {
  margin: 2em 5em }

div.abstract p.topic-title {
  font-weight: bold ;
  text-align: center }

div.attention, div.caution, div.danger, div.error, div.hint,
div.important, div.note, div.tip, div.warning, div.admonition {
  margin: 2em ;
  border: medium outset ;
  padding: 1em }

div.attention p.admonition-title, div.caution p.admonition-title,
div.danger p.admonition-title, div.error p.admonition-title,
div.warning p.admonition-title {
  color: red ;
  font-weight: bold ;
  font-family: sans-serif }

div.hint p.admonition-title, div.important p.admonition-title,
div.note p.admonition-title, div.tip p.admonition-title,
div.admonition p.admonition-title {
  font-weight: bold ;
  font-family: sans-serif }

div.dedication {
  margin: 2em 5em ;
  text-align: center ;
  font-style: italic }

div.dedication p.topic-title {
  font-weight: bold ;
  font-style: normal }

div.figure {
  margin-left: 2em }

div.footer, div.header {
  font-size: smaller }

div.line-block {
  display: block ;
  margin-top: 1em ;
  margin-bottom: 1em }

div.line-block div.line-block {
  margin-top: 0 ;
  margin-bottom: 0 ;
  margin-left: 1.5em }

div.sidebar {
  margin-left: 1em ;
  border: medium outset ;
  padding: 0em 1em ;
  background-color: #ffffee ;
  width: 40% ;
  float: right ;
  clear: right }

div.sidebar p.rubric {
  font-family: sans-serif ;
  font-size: medium }

div.system-messages {
  margin: 5em }

div.system-messages h1 {
  color: red }

div.system-message {
  border: medium outset ;
  padding: 1em }

div.system-message p.system-message-title {
  color: red ;
  font-weight: bold }

div.topic {
  margin: 2em }

h1 {
  font-family: Arial, sans-serif;
  font-size: 20px;
}

h1.title {
 text-align: center;
 font-size: 32px;
}

h2 {
 font-size: 16px;
 font-family: Arial, sans-serif;
}

h2.subtitle {
  text-align: center }

h3 {
 font-size: 12px;
 font-family: Arial, sans-serif;
}

hr {
  width: 75% }

ol.simple, ul.simple {
  margin-bottom: 1em }

ol.arabic {
  list-style: decimal }

ol.loweralpha {
  list-style: lower-alpha }

ol.upperalpha {
  list-style: upper-alpha }

ol.lowerroman {
  list-style: lower-roman }

ol.upperroman {
  list-style: upper-roman }

p.attribution {
  text-align: right ;
  margin-left: 50% }

p.caption {
  font-style: italic }

p.credits {
  font-style: italic ;
  font-size: smaller }

p.label {
  white-space: nowrap }

p.rubric {
  font-weight: bold ;
  font-size: larger ;
  color: maroon ;
  text-align: center }

p.sidebar-title {
  font-family: sans-serif ;
  font-weight: bold ;
  font-size: larger }

p.sidebar-subtitle {
  font-family: sans-serif ;
  font-weight: bold }

p.topic-title {
  font-weight: bold }

pre.address {
  margin-bottom: 0 ;
  margin-top: 0 ;
  font-family: serif ;
  font-size: 100% }

pre.line-block {
  font-family: serif ;
  font-size: 100% }

pre.literal-block, pre.doctest-block {
  margin-left: 2em ;
  margin-right: 2em ;
  background-color: #eeeeee;
  border-color: #000000;
  border-width: thin; 
  font-size: 14px
}

span.classifier {
  font-family: sans-serif ;
  font-style: oblique }

span.classifier-delimiter {
  font-family: sans-serif ;
  font-weight: bold }

span.interpreted {
  font-family: sans-serif }

span.option {
  white-space: nowrap }

span.option-argument {
  font-style: italic }

span.pre {
  white-space: pre }

span.problematic {
  color: red }

table {
  margin-top: 0.5em ;
  margin-bottom: 0.5em }

table.citation {
  border-left: solid thin gray ;
  padding-left: 0.5ex }

table.docinfo {
  margin: 2em 4em;
}

table.footnote {
  border-left: solid thin black ;
  padding-left: 0.5ex }

td, th {
  padding-left: 0.5em ;
  padding-right: 0.5em ;
  vertical-align: top }

th.docinfo-name, th.field-name {
  font-weight: bold ;
  text-align: left ;
  white-space: nowrap;
  }

h1 tt, h2 tt, h3 tt, h4 tt, h5 tt, h6 tt {
  font-size: 100% }

tt {}

ul.auto-toc {
  list-style-type: none }

</style>
</head>
<body>
<div class="document" id="basic-platform-independent-non-volatile-storage-layers">
<h1 class="title">Basic Platform Independent Non-Volatile Storage Layers</h1>
<table class="docinfo" frame="void" rules="none">
<col class="docinfo-name" />
<col class="docinfo-content" />
<tbody valign="top">
<tr class="field"><th class="docinfo-name">TEP:</th><td class="field-body">129</td>
</tr>
<tr class="field"><th class="docinfo-name">Group:</th><td class="field-body">Storage Working Group</td>
</tr>
<tr class="field"><th class="docinfo-name">Type:</th><td class="field-body">Documentary</td>
</tr>
<tr><th class="docinfo-name">Status:</th>
<td>DRAFT</td></tr>
<tr class="field"><th class="docinfo-name">TinyOS-Version:</th><td class="field-body">2.x</td>
</tr>
<tr><th class="docinfo-name">Authors:</th>
<td>David Moss
<br />Junzhao Du
<br />Prabal Dutta
<br />Deepak Ganesan
<br />Kevin Klues
<br />Manju
<br />Ajay Martin
<br />and Gaurav Mathur</td></tr>
</tbody>
</table>
<div class="note">
<p class="first admonition-title">Note</p>
<p class="last">This memo documents a part of TinyOS for the TinyOS Community, and
requests discussion and suggestions for improvements.  Distribution
of this memo is unlimited. This memo is in full compliance with
TEP 1.</p>
</div>
<div class="section">
<h1><a id="abstract" name="abstract">Abstract</a></h1>
<p>The storage abstractions proposed by TEP 103 are implemented on a
platform-dependent basis.  A version of BlockStorage, ConfigStorage,
and LogStorage were created from the ground up for both the
AT45DB and ST M25P80 flash chips.  Looking forward into the further
growth and development of hardware, rebuilding each of these storage
layers for every new flash chip will be time consuming and cause
compatibility issues.</p>
<p>We propose versions of BlockStorage, ConfigStorage, and LogStorage
be built on top of a platform-independent interface.  This would
allow one version of each to exist on multiple platforms.
Platform-independent implementation concepts are discussed
along with recommended solutions, and changes are proposed to the
interfaces defined by TEP 103.</p>
</div>
<div class="section">
<h1><a id="introduction" name="introduction">1. Introduction</a></h1>
<p>The implementations of the BlockStorage, ConfigStorage, and LogStorage
layers described in TEP 103 <a class="footnote-reference" href="#id6" id="id1" name="id1">[1]</a> are platform-dependent.  Platform-
dependent implementations can cause behavioral and usage differences
as well as compiling problems when attempting to port an application
written on one platform to another.</p>
<p>Building upon the DirectStorage, DirectModify, and VolumeSettings
abstraction layers defined in TEP128 <a class="footnote-reference" href="#id7" id="id2" name="id2">[2]</a>, the three basic storage
solutions can be implemented in a platform-independent manner.
This requires combining all properties of various memory types,
which aids in the creation of platform-independent storage solutions.
Behavioral differences are minimized, and applications using
the platform-independent storage layers can expect to work the
same way on different types of non-volatile memory.</p>
</div>
<div class="section">
<h1><a id="implementing-a-platform-independent-blockstorage" name="implementing-a-platform-independent-blockstorage">2. Implementing a platform-independent BlockStorage</a></h1>
<p>The DirectStorage interface initially stemmed from the BlockStorage
interface with differences in interfaces, organization, and
erase behavior, as well as the additional VolumeSettings interface.
To implement BlockStorage on DirectStorage, the erase behavior must
be extended to erase the entire volume instead of an individual erase unit.</p>
<p>VolumeSettings can first be accessed to determine the total number of erase
units in the currently mounted volume.  Looping through these erase units,
DirectStorage is accessed to erase() each one.  At the end of the erase
operation, the entire volume is set back to fill bytes (0xFF).</p>
<div class="section">
<h2><a id="improved-blockstorage-interface" name="improved-blockstorage-interface">2.1 Improved BlockStorage interface</a></h2>
<p>Previous BlockStorage interfaces were divided into BlockRead and
BlockWrite.  This was found to be cumbersome because applications
typically required access to both interfaces.  The getSize() is
unnecessary due to the addition of the VolumeSettings interface.
All other BlockStorage commands can simply pass through to their
respective DirectStorage functions. This TEP proposes the following
unified BlockStorage interface::</p>
<pre class="literal-block">
interface BlockStorage {

  command error_t read(uint32_t addr, void *buf, uint32_t len);

  command error_t write(uint32_t addr, void *buf, uint32_t len);

  command error_t erase();

  command error_t flush();

  command error_t crc(uint32_t addr, uint32_t len, uint16_t baseCrc);



  event void readDone(uint32_t addr, void *buf, uint32_t len, error_t error);

  event void writeDone(uint32_t addr, void *buf, uint32_t len, error_t error);

  event void eraseDone(error_t error);

  event void flushDone(error_t error);

  event void crcDone(uint16_t calculatedCrc, uint32_t addr, uint32_t len, error_t error);

}
</pre>
<dl class="docutils">
<dt><tt class="docutils literal"><span class="pre">read(uint32_t</span> <span class="pre">addr,</span> <span class="pre">void</span> <span class="pre">*buf,</span> <span class="pre">uint32_t</span> <span class="pre">len);</span></tt></dt>
<dd><ul class="first last simple">
<li>Read 'len' bytes into <tt class="docutils literal"><span class="pre">*buf</span></tt> from the given address</li>
<li>Returns FAIL if the request cannot be handled</li>
<li>Signals readDone(...) when complete.</li>
</ul>
</dd>
<dt><tt class="docutils literal"><span class="pre">write(uint32_t</span> <span class="pre">addr,</span> <span class="pre">void</span> <span class="pre">*buf,</span> <span class="pre">uint32_t</span> <span class="pre">len);</span></tt></dt>
<dd><ul class="first last simple">
<li>Write 'len' bytes from <tt class="docutils literal"><span class="pre">*buf</span></tt> starting at the given address</li>
<li>Returns FAIL if the request cannot be handled</li>
<li>Signals writeDone(...) when complete.</li>
</ul>
</dd>
<dt>erase();</dt>
<dd><ul class="first last simple">
<li>Erase the entire volume</li>
<li>Returns FAIL if the request cannot be handled</li>
<li>Signals eraseDone(...) when complete.</li>
</ul>
</dd>
<dt>flush()</dt>
<dd><ul class="first last simple">
<li>All data that has been previously written and is not yet located on
non-volatile memory should be immediately stored to non-volatile memory.</li>
<li>Returns FAIL if the operation cannot be completed at this time</li>
<li>Signals flushDone(...) when complete.</li>
</ul>
</dd>
<dt>crc(uint32_t addr, uint32_t len, uint16_t baseCrc);</dt>
<dd><ul class="first last simple">
<li>Calculate the CRC of 'len' bytes starting at the given address, using
the given baseCrc as a seed.</li>
<li>Returns FAIL if the request cannot be handled</li>
<li>Signals crcDone(...) when complete.</li>
</ul>
</dd>
</dl>
</div>
</div>
<div class="section">
<h1><a id="implementing-a-platform-independent-logstorage" name="implementing-a-platform-independent-logstorage">3. Implementing a platform-independent LogStorage</a></h1>
<p>As described in TEP 103, logging can be implemented using two
different methods: linear and circular.  A linear log fills up
its volume and stops when it comes to the end.  A circular log allows
at least half of its volume to remain valid while continuing to write
the other half.  As previously described, this requires at least
two erase units to be effective.</p>
<p>Both logging behaviors can be implemented using the same code.
A flag for linear log behavior prevents the logger from
freeing up an erase unit in which to continue writing.</p>
<p>It should also be noted that the use of a circular log mandates
the use of at least two erase units on the volume.  As discussed
in TEP128 <a class="footnote-reference" href="#id7" id="id3" name="id3">[2]</a>, forcing volumes to contain at least two erase
units solves this issue.</p>
<div class="section">
<h2><a id="logstorage-boot-behavior" name="logstorage-boot-behavior">3.1 LogStorage Boot Behavior</a></h2>
<p>In the previous LogStorage implementations, reboots cause data to be
lost or overwritten because the beginning and ends of the log were
never located. Preventing previously stored data from being lost
or overwritten after reboot is critical for the successful use and
integration of logging storage components within a practical,
deployable system.</p>
<p>A method is required on boot to locate the first memory location to
read from as well as the next available memory location to write to.
Although one method is to use microcontroller user memory
to store the information, the goal is to avoid relying on external
support due to cross-platform compatibility reasons. Luckily, storing
and updating this information on the volume itself is easier than
it seems.</p>
<p>Flash cannot overwrite areas of memory it has already written without
performing a read-modify-write operation, and this operation is
not supported on many flash types.  Regardless of whether the memory
type can support modifications, all types of memory - including EEPROM -
should take wear-leveling into account.  Combining these properties,
it is possible to design a method of maintaining and updating logging
start and stop information in a cross-platform compatible manner.</p>
<p>The method of locating logging properties on boot is simplified by making
entries aligned to erase unit boundaries, never allowing a single
entry to bridge erase units.  This also prevents invalid entries
from being created as a result of erasing an erase unit.</p>
<p>To find the first available write address to add new log entries,
the first header entry on each erase unit is evaluated to find the
greatest 32-bit &quot;cookie&quot; value that is not fill-bytes (0xFFFFFFFF).
The erase unit with the largest value contains the newest data.
Next, each entry in that erase unit can be iterated through by reading
each header and skipping the length of the header + data, until a
header with the value 0xFFFFFFFF is located.  The address of this
location is the first available address to write.</p>
<p>Finding the first available address for reading involves the same process.
The first header entry on each erase unit is evaluated to find the lowest
32-bit &quot;cookie&quot; value.  The entry with the lowest value is the beginning
of the log.</p>
<p>The first entry to read from and last address to write to MUST be
located on platform boot.</p>
</div>
<div class="section">
<h2><a id="appending-log-entries" name="appending-log-entries">3.2 Appending log entries</a></h2>
<p>The previous M25P80 log storage implementation is a good place to start.
In it, each write consists of a 32-bit header &quot;cookie&quot; and the data to
be appended to the log.  Locating the beginning of the log is therefore
a matter of finding the lowest header cookie value.  If this were to be
implemented so entries align with erase unit boundaries, only the
first header of each erase unit needs to be checked for the lowest value.</p>
<p>32-bits leaves plenty of space to increment log entry values for.
If the log were to append one chunk of data every second, it would
take 136.1 years before the 32-bit header recycles to 0 and causes
an issue in properly locating the first and last log entries.
This is well beyond the expected lifetime of a deployed system.</p>
<p>Each header entry can provide additional support for every
data entry by allowing it to track the amount of appended data as well
as an optional 8-bit CRC to verify the data is valid::</p>
<pre class="literal-block">
typedef struct log_header_t {
  uint32_t cookie;
  uint8_t length;
  uint8_t crc;
} log_header_t;
</pre>
<p>When the logger appends to the next erase unit boundary, it can first erase
it to ensure future appends are not corrupted by existing bytes. At the
point where it reaches the end of its volume, the 'circular' logging
flag can be used to determine if the logger should go back to the
beginning of the volume and continue writing.  Again, this is performed
in conjunction with the VolumeStorage interface to determine erase unit
properties.</p>
</div>
<div class="section">
<h2><a id="reading-log-entries" name="reading-log-entries">3.3 Reading log entries</a></h2>
<p>After the first log entry is located, entries are extracted by first
reading the header of a single entry, and using the information from
the header to pull out the subsequent log information.  After each read,
the read pointer is updated to point to the read location of the next header.</p>
<p>If the header ID is fill bytes (0xFFFFFFFF), then the entry is
invalid and the read process has reached the end of the log. As with
the ST M25P80 implementation, entries may be randomly seeked by
providing the 32-bit &quot;cookie&quot; identifier to locate.</p>
</div>
<div class="section">
<h2><a id="logging-conclusions" name="logging-conclusions">3.5 Logging conclusions</a></h2>
<p>This proposed logging storage solution will provide the
ability to maintain and locate previously logged data as well as
support truly circular logs by mandating more than one erase unit per
volume.  Behavioral differences between flash chip implementations
are eliminated so one application can access logging storage across
all platforms.  Furthermore, reboots will not cause logged information
to be lost or overwritten.</p>
<p>Existing LogRead and LogWrite interfaces defined in TEP 103 <a class="footnote-reference" href="#id7" id="id4" name="id4">[2]</a> are
sufficient to implement cross-platform logging abilities.</p>
</div>
</div>
<div class="section">
<h1><a id="implementing-a-platform-independent-configstorage" name="implementing-a-platform-independent-configstorage">4. Implementing a platform-independent ConfigStorage</a></h1>
<p>The previous interface to ConfigStorage looks very similar to that
of BlockStorage.  The ConfigStorage interface allows reads and
writes to arbitrary addresses, which is not optimal.  One critical
concept behind the storage of configuration data is the ability to
modify and overwrite existing parameters while preventing surrounding
data from being corrupted.  The former ConfigStorage definition did
not support this, so a new solution should be explored and developed.</p>
<p>This new solution should prevent an application from specifying
addresses to read and write to on the volume.  Instead, it should dictate
addresses underneath, not allowing applications to see those addresses.
In essence, the solution should handle the allocation of memory and
take the burden of determining valid addresses off of the application
layer.  This will allow it to support multiple components written by
different authors on the same system.</p>
<div class="section">
<h2><a id="hash-based-configuration-storage" name="hash-based-configuration-storage">4.1 Hash-based configuration storage</a></h2>
<p>Several practical deployments have demonstrated the effectiveness of
a hash-based configuration storage solution.  In it, any module
in a system can store and update any type of data of any size without
destroying other modules' information.</p>
<p>The implementation is similar to that of ConfigStorage in that each
entry contains a header followed by a variable amount of data.
The header is different than ConfigStorage headers in that instead
of containing a 32-bit cookie, it contains a 32-bit hash key and
a magic number to keep track of state::</p>
<pre class="literal-block">
typedef struct config_header_t {
  uint32_t hashId;
  uint8_t magic;
  uint8_t length;
  uint8_t crc;
} config_header_t;
</pre>
<p>The magic number allows Configuration storage to determine if the
entry is valid or has been deleted.  Because non-volatile memory typically
writes from 1's to 0's, the magic number can take on a finite number of
values before it is filled with 0's.  For example::</p>
<pre class="literal-block">
enum {
  ENTRY_EMPTY = 0xFF,
  ENTRY_VALID = 0xEE,
  ENTRY_INVALID = 0xDD,
};
</pre>
<p>Configuration data can be stored and retrieved by indexing it with
a hash key. Like AM types in the radio stack <a class="footnote-reference" href="#id8" id="id5" name="id5">[3]</a>, each key is uniquely
defined by the developer.</p>
<p>Each new update to the configuration storage should create an entirely
new entry while invalidating any previous entry containing the same hash key.
Optionally, a small cache in RAM can be used to maintain information about
where existing hash ID's are located in memory, so non-volatile memory
does not need to be traversed each time.</p>
<p>When space runs out on one erase unit, the next erase unit can be used
to copy in all valid data from the first.  The first erase unit can
then be erased.  This allows parameters and configuration data to be
infinitely updated so long as the amount of valid data plus supporting
headers is less than half the volume's total erase unit size.</p>
</div>
<div class="section">
<h2><a id="improved-configstorage-interface" name="improved-configstorage-interface">4.2 Improved ConfigStorage interface</a></h2>
<p>The interface to access the configuration storage mechanism is proposed
as follows, allowing the application layer to continually update
previously stored parameters while preventing it from accessing
memory addresses directly::</p>
<pre class="literal-block">
interface ConfigStorage {

  command error_t getTotalKeys();

  command error_t insert(uint32_t key, void *value, uint16_t valueSize);

  command error_t retrieve(uint32_t key, void *valueHolder, uint16_t maxValueSize);

  command error_t remove(uint32_t key);

  command error_t getFirstKey();

  command uint32_t getLastKey();

  command error_t getNextKey(uint32_t presentKey);


  event void inserted(uint32_t key, void *value, uint16_t valueSize, error_t error);

  event void retrieved(uint32_t key, void *valueHolder, uint16_t valueSize, error_t error);

  event void removed(uint32_t key, error_t error);

  event void nextKey(uint32_t nextKey, error_t error);

  event void totalKeys(uint16_t totalKeys);

}
</pre>
<dl class="docutils">
<dt>getTotalKeys()</dt>
<dd><ul class="first last simple">
<li>Determine the total number of valid keys stored on non-volatile memory</li>
<li>Signals totalKeys(...) when complete</li>
</ul>
</dd>
<dt><tt class="docutils literal"><span class="pre">insert(uint32_t</span> <span class="pre">key,</span> <span class="pre">void</span> <span class="pre">*value,</span> <span class="pre">uint16_t</span> <span class="pre">valueSize)</span></tt></dt>
<dd><ul class="first last simple">
<li>Insert some data into the configuration storage associated with the
given key</li>
<li>Signals inserted(...) when complete</li>
</ul>
</dd>
<dt><tt class="docutils literal"><span class="pre">retrieve(uint32_t</span> <span class="pre">key,</span> <span class="pre">void</span> <span class="pre">*valueHolder,</span> <span class="pre">uint16_t</span> <span class="pre">maxValueSize)</span></tt></dt>
<dd><ul class="first last simple">
<li>Retrieve the value associated with the given key.  The maximum value
size is the maximum amount of data that can be loaded into the
<tt class="docutils literal"><span class="pre">*valueHolder</span></tt> location, to avoid overflow</li>
<li>Signals retrieved(...) when complete</li>
</ul>
</dd>
<dt>remove(uint32_t key)</dt>
<dd><ul class="first last simple">
<li>Removes the given key and its associated values from non-volatile memory</li>
<li>Signals removed(...) when complete</li>
</ul>
</dd>
<dt>getFirstKey()</dt>
<dd><ul class="first last simple">
<li>Determines the first key available for reading on non-volatile memory</li>
<li>Signals nextKey(...) when complete</li>
</ul>
</dd>
<dt>getNextKey(uint32_t presentKey)</dt>
<dd><ul class="first last simple">
<li>Obtain the next available key on non-volatile memory based on the
current key.  Allows the application to traverse through all stored
keys.</li>
<li>Signals nextKey(...) when complete</li>
</ul>
</dd>
<dt>getLastKey()</dt>
<dd><ul class="first last simple">
<li>Returns last key available for reading on non-volatile memory.</li>
<li>This value is assumed to be located in cache, so it can
return immediately</li>
</ul>
</dd>
</dl>
</div>
</div>
<div class="section">
<h1><a id="author-s-address" name="author-s-address">5. Author's Address</a></h1>
<div class="line-block">
<div class="line">David Moss</div>
<div class="line">Rincon Research Corporation</div>
<div class="line">101 N. Wilmot, Suite 101</div>
<div class="line">Tucson, AZ  85750</div>
<div class="line"><br /></div>
<div class="line">phone - +1 520 519 3138</div>
<div class="line">phone - +1 520 519 3146</div>
<div class="line">email ? <a class="reference" href="mailto:dmm&#64;rincon.com">dmm&#64;rincon.com</a></div>
<div class="line"><br /></div>
<div class="line">Junzhao Du</div>
<div class="line">Contact -</div>
<div class="line"><br /></div>
<div class="line">Prabal Dutta</div>
<div class="line">Contact -</div>
<div class="line"><br /></div>
<div class="line">Deepak Ganesan</div>
<div class="line">Contact -</div>
<div class="line"><br /></div>
<div class="line">Kevin Klues</div>
<div class="line">Contact -</div>
<div class="line"><br /></div>
<div class="line">Manju</div>
<div class="line">Contact -</div>
<div class="line"><br /></div>
<div class="line">Ajay Martin</div>
<div class="line">Contact -</div>
<div class="line"><br /></div>
<div class="line">Gaurav Mathur</div>
<div class="line">Contact -</div>
</div>
</div>
<div class="section">
<h1><a id="citations" name="citations">6. Citations</a></h1>
<table class="docutils footnote" frame="void" id="id6" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id1" name="id6">[1]</a></td><td>TEP 103: Permanent Data Storage (Flash).</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id7" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id7">[2]</a></td><td><em>(<a class="fn-backref" href="#id2">1</a>, <a class="fn-backref" href="#id3">2</a>, <a class="fn-backref" href="#id4">3</a>)</em> TEP 128: Platform independent Non-Volatile Storage Abstraction Layers</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id8" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a class="fn-backref" href="#id5" name="id8">[3]</a></td><td>TEP 116: Packet Protocols</td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id9" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id9">[4]</a></td><td>Atmel AT45DB041B datasheet. <a class="reference" href="http://www.atmel.com/dyn/resources/prod_documents/DOC1432.PDF">http://www.atmel.com/dyn/resources/prod_documents/DOC1432.PDF</a></td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id10" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id10">[5]</a></td><td>ST M25P80 datasheet. <a class="reference" href="http://www.st.com/stonline/products/literature/ds/8495/m25p80.pdf">http://www.st.com/stonline/products/literature/ds/8495/m25p80.pdf</a></td></tr>
</tbody>
</table>
<table class="docutils footnote" frame="void" id="id11" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<tr><td class="label"><a name="id11">[6]</a></td><td>K9K1G08R0B datasheet. <a class="reference" href="http://www.samsung.com/Products/Semiconductor/NANDFlash/SLC_SmallBlock/1Gbit/K9K1G08R0B/ds_k9k1g08x0b_rev10.pdf">http://www.samsung.com/Products/Semiconductor/NANDFlash/SLC_SmallBlock/1Gbit/K9K1G08R0B/ds_k9k1g08x0b_rev10.pdf</a></td></tr>
</tbody>
</table>
</div>
</div>
</body>
</html>
